I'm not sure we will want to tag on every push to main - but I'm totally fine leaving this as-is and addressing in the future, once we have a better idea of what we DO want

Ok! I'm inclined to tag on every push to main, but agreed - let's leave as-is and we'll address it in the future once we've had a chance to discuss!

Will these be included in, or required by, the final jar we publish to artifactory? I haven't tried it myself to see what the results are. If these ARE included or required, can that be prevented, potentially by choosing a configuration other than implementation? We want the published jar to be as small and as dependency-free as possible; and these are only used by build tasks, not at runtime, correct?

I'm fine fixing this in a follow-on PR if you want to defer this work.

Great point, I will make sure this is covered with AJ-1095

This file (buildSrc/build.gradle) is different than other gradle project configuration files. It's (normally) only used to configure plugins, and its "dependencies" block only affects the plugins loaded by gradle, not compile or runtime dependencies used when running gradle tasks.

So these dependencies have no effect on the jar published to artifactory. They're here so when a plugin is used elsewhere in the project you don't need to specify the version. It provides a way to make sure that the same plugin versions are used in all subprojects.

With that in mind, the repositories block should only include those that are needed to load plugins. In my project I use:

repositories {
    maven {
        url 'https://broadinstitute.jfrog.io/artifactory/plugins-snapshot'
    }
    gradlePluginPortal()
}

The artifactory configuration is needed for the terra-test-runner plugin which is locally published. If you aren't using that plugin then gradlePluginPortal() should be sufficient.

Also I'd remove the test block below. I don't think it has any effect, and it should go in one of the plugin subprojects instead.

@pshapiro4broad thanks for this context, I think I understand the buildSrc setup a little better now.

Not sure if you want to do it now, but I think this should use picocli's dynamic version support and use the data generated by the gradle-git-properties plugin. That would help confirm that the git-properties plugin is working as expected.

Ok! I started taking a look at this, but I think this PR is at a good stopping point to be merged. So, I will take a look at this with my next chunk of publishing work!

I also wanted to set up sonar scanning for a project that has multiple gradle subprojects but hadn't looked into it yet. i think there's a way to combine scans (and code coverage data) across different subprojects, did you look into doing it this way before running the scans as separate projects? How does this work on PRs? Does it show the result of both scans?

Great question -- I was hoping to use the monorepo setup that's available for sonarcloud that I think should do what you're talking about. But, it's really hard to fiddle with settings because engineers don't have access to the admin settings on sonarcloud. Tom flipped the monorepo switch on the project, but as far as I could tell, nothing changed. The two projects still went into two separate sonarcloud projects.

This technically works -- I have two steps in GHA that runs against the two projects. Sonarcloud comments twice in the PR, once for each project (unfortunately, the comments don't distinguish between the two projects).

I think this is good enough for now, but I would definitely be interested in looking at the monorepo setup more -- this would require more time from infosec or more permissions in sonarcloud.